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Notes on: 

Placing the functional modules of TENEX Into management processors., 



Qualification 

The following notes are not necessarily organized In a logical 
manner. They represent many observations and thoughts concerning the 
above topic. Several purposes d^re intended for these notes. A fr^-^t 
gathering of the various "loose" thoughts is Intended. This *^111 te 
Vr'orked Into a more formal memo or report. A me«ns of conynunicatlcn "o 
other members of the task as to the nature of moves to managemerit 
processors as I see It, In conjunction with that, to receive comments 
from others as to 

1) disagreements with rny observations and thoughts 

2) further development or Insights Into the topics mentioned 

3) as a booster to others to pursue or plan towards certain aspects 
of the topics mentioned. 

Periodic Routines 



There are mar^y cyclic, time-dependent routines that must be Invoked 
by the scheduler In its main loop. The scheduler uses the system clock 
to update routine clocks to determine when to run^tRese routines. These 
roatlnes can be placed in the manageme nt processors which maintain their 
own querying cycles. Some of these routines are 

1) TTCH7 to check for terminal transmission, etc. echoes. 

2) IMP 

3) DSKCHK (?) specific function needs to be specified, 

4) r^rrACKK (?) specific function needs to be specified 
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Blocks and Wakeyps 

Presently the following scenario occurs for blocks md wakeups* 
To block a process, a function in some other part of the operating system makes 
a well -defined entry Into the scheduler. State Is saved, md the process 
Is blocked. Slocking involves setting a word In a system fcrk table 
for the fork being blocked. This word containing a test comlitlon and 
a transfer address of a test routine. The scheduler In its min loop 
runs through these tests to see If a fork should be waken (periodically 
depending on the 1SK£D flag). Upon wakening, the scheduler mo^es the 
fork from the wait to the go list. Many of these tests are In the 
scheduler (the DISMISS tests, BLOCK tests) but there are mny U the other 
parts of the operating system. 
These blcck^^^and^wakej^^ 
proces sors , The tests should be maintained at the local processor 
(As for modules that will continue to share the CRJ with the schedu"^t;r» 
assuming the scheduler Is not In a separate processor, the current scheme 
mqht be maintained), Instead of the scheduler tasting for wakeups, 
the separate processors ?dll i-^quest wakeups on a ring queue. Present!/ 
Jumps are made to certain routines In the scheduler (OSYS EDISMS. SCHEDP etc.) 
to cause a block. These should be changed to requests to block. 

We must find these routines and list them. 

Re- Entrant Consi derations 

Current}y the TEMEX system is re-entrant (to the greater extent). 
Explanation is given by the following example. Uhen a process blocks 

for a page fault, it might be In the memory manager. It calls the scheduler 
via SCHEDP and' the scheduler renumbers the current location in memory 
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management that the call came from. Also the state of the system necessary 
for that specific fork is saved 1n that process PSB (Process Storage Block). 
Another fork with a different PSB is then started up. Later on, when the 
page comes in for the original fork» and 1t reaches sufficient priority, 
the fork Is continued where It left off in the memory manager. 

There is no re-entrance into th e management p rocessor Its elf 
since It Is running independently of thft CPU, Observations of memory 
snanagement imply that certain parts of the code must remain outside 
of the processor itself. Thought must be given as to how re-entrantness 
(as currently implemented) affects the cut of code into processor and 
that remaining In the monitor. A rule of thumb Is that the more fork 
related, the more it must remain in the monitor. Actually a good idea 
Is to push the re-en trantness out of the memory manager as much as 
possible. This may involve more state keeping in the local tables or 
in the PSS. This problem and solution Is a good one to study for one 
rnodule (e.g. memory management) because it Is a case of the problem one 
encounters among all the nKjdules (I.e. peripherals module, file systan). 

Currently ^udy Is working on looking at PAGOIr the memory manager. 
Since I have studied the scheduler pretty thoroughly already, when she Is 
fairly familiar with PAGEM, then we can address ourselves to this problem 
in actual irriplementation detail. From this we will probably obtain 
guidelines with respect to the other management processors. 

Interrupts 

The interrupt scheme presently employed is complicated. It would 
be hard to convince oneself much less someone else of the security of the 
cocie Involved. With the addition of management processors, much of the 
^dTlernjpts can be renioved. The (ISE SCDCHN) which Is a form of 
programmed interrupt is used perhaps* too freely (from & security standpoint) 
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Hany times it is used to set up rescheduling and starting up of forks. 
Because much of the complexity of the scheduler will be removed (e.g. 
all the WAKEUP tests, periodic routines) it may be that the scheduler 
!ieed not be Interrupt driven. 

The clock does need to be updated though but this may be In an 
encapsulated function. The scheduler might be request driven more than 
Interrupt driven. 

To the extent that time-dependentness Is less a factor for the 
CPU^ the less role interrupts will take. 

Fork Tables 



Forks being the key processing unit, there are important tables 
that are maintained for active forks. These will probably come under 
protection. Protection mechanisms should be considered for these tables. 

Pseudo- 1 nterru)[>ts 

A fork table FKINT, and also FK1NT8 are definitely to be shared 
amofig various procsssoi-s. These perhaps would be Important elements to 
use In thinking of domain protection and control. (The fork tables In 
general provide a good case). The terminal handling processor will 
probably set these tables as well as the scheduler. E.9. fC received 
on a teletype will cause FKINT and FKINTB entries for that fork to be 
set, later the scheduler will see and hendle the pseudo-interrupt accordingly 
Similarly,, the APR processor overflow!; will generate such interrupts. 

Macro-scheduler and Micr o-scheduler 

It seems feasible to lave a macro-scheduler (part of monitor) ^n6 a 
mlcro-schediiler {in a processor). The micro-scheduler can handle the 
more tlme-dependent stuff (i.e. update clocks) while the macro-scheduler 
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handles the larger more general scheduling tasks such as LOGIN, LOGOUT. 
In factj the micro-scheduler might perform another task currently 
relegated to the macro-scheduler, that of determinimi when processes 
can be removed from the balance set. 

Domains > Data Structures 

The dotriains and data structures must be well cho?;cn and the functions 
or accesses to them well-defined in a multi-processor enviror-fnent. As 
mentioned earlier, hardware or software fences must b-: defined to limit 
access (of various types) to these domains. 

Relation to Critical-_%n critical Code, Insertion of Protect ior^vcj^a^njjms^ 

These two topics are firmly tied in with that which 
Is the subject of this discourse. The right hand must know what the .-.ft 
Jiand is doing. Discussions should be set up to coordinate efforts. 
e.g. Whet goes into a separate processor need not be worried as to whether 
it is critical or non-critical. 

J SYS Consideratio ns 

r r'n - ■- I I I r • Hill i^mai III III 

Movement into separate processors must be cognizant of the effect 
on JSYSes. One of the inherent problems is the same as that discussed 
in re-entrantness. The code the JSYS may want to execute may be in the 
processor. Thus the value of the above proposed discussions. A memo 
should be written concerning major problems of implementing OSYS caused 
by separate processors. Several bases of information are needed. 
A good understanding of the various JSYSes' Implementation, an understanding 
of the probable partition into processors which is being described here, 
md ability to combine JSVSes Into logical groups so that major properties 
and difficulties can be foreseen and thus worked on. 
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Details 

The actual implen>entation Involves overwhelming detail. But tor 
the system to run practically, all this detail must be gleaned, A 
comprehensive base of knowledge is an important requirement. This task 
of rfK)v1ng TENEX into separate processors should include several subtasks. 
Some of these have been already mentioned. But for example, 

1) concentrating on removing the peripheral stuff from the standpoint 
of the peripherals control processor. This Is perhaps the most 
inwedlately fruitful and practical area. 

2) similar for the memory manager 

3) general coordination, and problems to be encountered with all 
'processors. Setting up protection mechanisms and domain. 

4) concentrating on simplifying and formalizing the interfaces between 
processors. Creating feasible protection mechanisms. 

Protection Mechanisms 

Perhaps the least developed, but most interesting aspect is to be 
able to protect the important structures. This topic will be pursued soon. 
Various ideas (general in nature) have been proposed. At this point it 
iS feasible to consider some of these proposals and discuss them. Already, 
simplicity is a key. By making TENEX simpler, we can define it. formalize 
it better. Protection mechanisms to be inserted Into this new design 
can be considered. 

File System 



I haven't given much thought to the file system. But the following should 
be pursued. Should we. and how could we put the file system under separate 
control? Various terminal things have t9 be broken out of the file system. 

Rainer mentioned a high level cut. I would appreciate a memo on this. 
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The file system stuff perhaps will be more involved in critical-non critical 
than separate management processor. But lets not assume a priori that this 
is so. 

Protection Processor 

Really this relates to the protection mechanismi- mentioned earlier. 
But it is worthwhile to consider the possible role (also economics) of 
having such a processor. What kind of things could it do (both to 
prevent as well as signal violations of security). Actually it might 
be in the nature of a SYSDDT type processor except with different functions. 
Or like the HISHIMP process that checks queues, etc for 'alidity* sane 
of this, can be in microcode. From others experience and our ideas, such 
a processor might be yery important. 

Napping, SPT^ User/Honitor Modes. Fast Mon itor Routine. S'kiM Monitor 
This whole area seems like a bag of worms resulting 1 many gory 
special case checks and unbelievably messy code. We Biust v.mlyze this area 
carefully because there's a lot of broken glass around. Jir.v^ ts Intttally 
working on this stuff. 

LOlO Processor 

What anticipated problems can we expect with the LOLO prr.essor? 
The word size is 16 bits while TENEX addresses in general are 1? bits. 

Startup^ Initialization 

The startup code will be different in the new scheme since here is 
a major reorganization. Conventions nsed be set up to COLD STARf the 
various processors, and the necessary tables. Similar problems mtt be 
considered for system checkpoint/crash recovery. How is security 
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Intalned in such an Instance? 



Formal Def initions ^ Procedures 

As part of securing the system, sloppiness mast be avoided. It Is a 
cardinal sin. Procedure must be set up that cle^trly state, 1.e.» how 
data structures are accessed, who accesses them, ex. Further, constructions 
such as that of the protection domains (Spier) which force Implementation 
to follow strict procedures will be used. Part of the ij^plementatlon of 
security means prevention of sloppy programming. 

Seminar Proposition 

It is a good time to have a seminar on how the TENEX operatifig system 
functions. This would probably help many people .rasp the system. I have 
some knowledge from the scheduling standpoint. Conbine this vith th^^ 
file system and memory ifianageraent, we can perhaps present the activity 
going on when a job is run on the system. , 



